not really a problem, because you will never stream from the race server, but from a connected LFS client. Indeed you will have 2 different servers, one server is the race server and the other server is the sreaming server. And the location of the streaming server may be completely different from the location of the race server.
In fact, meanwhile streaming is commonly used by some leagues or for some events (especially 24 hour races).
and they have uploaded the streams too they are really worth to watch. Look here: http://www.esport-racing.com/media.php
(my favorite ones are the Aston North race, the Westhill race and the Aston National race of the International eTM)
in the IS_MCI packets you will receive the X and Y coords of all cars. You need to set the ISF_MCI flag in the IS_ISI packet and set the interval, then LFS will send you the IS_MCI packets.
now writing documentation, change logs, make testing and fix some minor bugs.
Coming soon:
- Insim support for Patch X and later
- Devided the application into 2 separate executables (GUI and Control)
- GUI lets you control cameras manually (useful for professional broadcasters)
- Action detection completely rewritten (still based only on distance but in a much smarter way)
- Output of standings, driver information, lapcount or racetime (see attached screenshot)
during my tests I found that IS_SFP seems not to work in some cases. I am able to switch the ISS_SHOW_2D off, but after this I can not switch it on. Sometimes it seems to work and sometimes not.
Can somebody confirm this behaviour?
Version LFS S2X
unknown software exception @ address 0x004b2ad1 (see attachment)
Crash occured during some tests with my insim application. It seems that LFS has received uninitialized CPP packets.
This crash is similar to this one but the crash address is different.
because IS_MSL packets can not be used for commands, I would need to use IS_MST. But these messages can be seen on other hosts. So does anybody know, if this is also true for commands?
E.g. if I want to assign a text to the Ctrl+F6 Button on my keyboard, so I need to send a IS_MST packet with /ctrlf 6 text. I want to make sure that other clients are not affected by this.
You can use the LFS TV Director. This tool utilizes the shift-U cameras and you can set the positions of the cameras wherever you want.
Unfortunately the current (released) version of this tool only supports the old Insim Version (until patch V). For use with patch X you need the Insim Gateway (v3->v4) additionally. Or just wait for the next release.
Look at this video of the latest eTM race to get an idea how watching a race will look like with the TV Director (you can find streams of all eTM races at their website, they are quite worth to watch and Vykos is doing a great job as commentator ).
with kind regards
Soeren
Last edited by Soeren Scharf, .
Reason : links added
with patch X10 the "force cockpit view" option was introduced, but I can not find any related flag, packet, or whatever in the insim.txt.
So I wonder how my insim application can detect, if this option is active?
very easy to reproduce, get this exception too. It happens when sending a IS_CPP in shift-u mode with a pitch value of 16384 (or somewhere around this value), so making the cam looking upright down.
This is only half the truth. Indeed for race tracking there is some trouble due to fiddling about the old connection numbers. But from technical point of view I can not see any issue why outgauge and outsim should not work.... if someone is willing to implement the conversion of these few packets or... if there is a strong demand for one particular packet I would also do this.
And this is the other half of the truth, the response in the project's thread was very poor. Neither from other programmers nor from a user I have received any useful hint or request. I have posted the complete source code in the programmers forum, but there was no comment about current issues in my source code. I have also posted the complete source code, because I am too busy. I was hoping that somebody else would continue... no chance. It seems that there is not that much interest, so I discontinued this project.
Don't get me wrong! I would really like to continue the project (at least the things what is possible). But not without demand and without help.
I wrote, that this is not a problem, really. And to add some additional words, what I wrote is the way, how I would implement his request.
As you already wrote, it is not possible to prevent someone from spectating or pitting (the button idea will also be useless because of short cuts on the keyboard). Therefore I would prevent the player from rejoining after pitting from an invalid place (kicking him into spectationg mode after an unallowed rejoin). This is possible and easy to implement.
If you have a better idea, please tell.
The problem is not to prevent someone from spectating or pitting, but to prevent him from rejoining after pitting (if not pitted from pitlane position) or spectating. And this is not really a problem.
well, I have attached the source code of the Insim Gateway (Insim v3 to v4) into the Insim Gateway thread too. It is not too complex at the moment, so it might be a good starting point. Also it shows you both TCP and UDP sockets.
And maybe (hopefully) you will be the person who continues this project. I cannot, because I need to continue the TV Director project.
look at the attached picture, this should make things clear.
textual description:
1. I suggest to start first the Gateway and LFS. In LFS you need to type the command to enable insim.
2. And last you connect from the insim application (e.g. TV Director). This may require, that you shortly need to switch LFS into windowed mode, after this step you can switch back to fullscreen.
This is the reason why I have added the source code
You can use the current version with patch X too. Download the Insim Gateway to enable old insim addons to work with patch X. Hopefully this helps waiting for the next TV Director release.
Due to some requests in the addon forum and because there may be a lot of discontinued addon projects, I have started developing an insim gateway for conversion between insim v3->v4. I put this thread here in the Programmers Forum because it is more an initial release than a finished software tool. Therefore I also put the source code here, so other programmers would be able to find bugs, continue the project or improve the gateway further.
There are some issues in the current version, only some of them could be solved:
- currently no outsim and outgauge packet translation.
- if there are more than 28 drivers in a race, not all drivers can be reported to a V3 application (NLP packet in v3 can only accomodate 28 structures).
- gateway does not yet translate from car prefixes into car long names.
- gateway does not yet fill NumNodes and FinishLine in some structures.
- ConnNum cannot be filled correcly, using UCID instead (migth be wrong).
- PlyNum cannot be filled correcly, translation from PLID into PlyNum seems to fail somehow.
I have tested with:
- LFS Tv Director -> works, no known issues
- noobTV -> works partially, issues with custom cameras, custom external cams not tested.
03.09.07 Update
- removed waiting for 2 sockets with select (crashed on some PCs), use polling now
- fixed size in call to recv
_____________________________
Last edited by Soeren Scharf, .
Reason : update and bugfix
there are some serious issues in this task. The main problem is, that Scawen has thrown away unnecessary information (e.g. ConnNum, instead using UCID what is not the same) and removed redundant information (e.g. nicknames only in IS_NCN and IS_NPL but no longer in IS_CNL, IS_PLP, IS_PLL ....). Therefore such a bridge would need to keep track of a lot of information or needs to ask LFS for further information to translate one packet. And in some cases it would need to generate the information itself at all (e.g. PlyNum, ConnNum...).
Nevertheless I am working on such a tool (for 3 weeks now). There will be no guarantee that it will work with every addon, indeed I will not implement translation for all the packages. But I will release the source code too (soon).
much to my regret you have removed the NumPlayers and FirstPly from the MCI packet some time ago. Now it is hard to detect if I have received a complete set of MCI packets. For instance if there are exactly 16 or 24 players in list, I would not know what is the first and what is the last MCI packet, all packets contain 8 valid CompCar structs.
Is there any chance to get this information back?